Various service oriented software platforms have been developed for building distributed enterprise applications. One example of such a system is the Java 2 Platform, Enterprise Edition (“J2EE”) from Sun Microsystems, Inc. In existing service oriented software platforms, infrastructure services are typically very generic, in order to serve a lowest common denominator of requirements for all higher level application components. However, though these generic infrastructure services fit the requirements of most higher level application components, some application components may have requirements that are not met. To address this problem, higher level application components may be forced to re-implement infrastructure services to meet their specific needs, or find other ways to make behavioral changes to the generic services provided.
For example, in previous systems, such as IBM® Lotus Workplace™, higher level application components have themselves run specific business logic before calling infrastructure services, or internally re-implemented services to meet their specific needs. This approach requires significant coding by the application component developer, and limit code reuse. When higher level, component-specific service-related business logic is included within higher level components, overall system maintenance may be difficult.
Other previous systems have included an event broker to dispatch method calls and provide higher level application components with software “hooks” into other higher level application components. An example of such an approach is the Common Event Infrastructure (CEI) technology provided by International Business Machines Corporation. However, these technologies do not help higher level application components fully control the flow of service methods, do not allow changing arguments or return values of the infrastructure service methods, and/or changing or canceling execution flow in connection with the use of such infrastructure service methods. As a result, significant coding within higher level components using the services may be necessary to provide individualized support. Existing publication/subscription based systems may be considered another example of event brokerage, and typically suffer from the same inherent problems.
The “Mediator Pattern” is a well known behavioral pattern involving an object that encapsulates how a set of objects interact. This approach promotes loose coupling of software objects by keeping objects from referring to each other explicitly, and allows some independent control of object interaction. While the Mediator Pattern approach allows for some argument transformation, both client and server software must follow the pattern to enable the transformation, and complete control over infrastructure service methods is not provided.
Internet Server Application Programming Interface (ISAPI) filters have been used to route or provide early termination of requests coming to a Web server. While some limited execution control is provided, ISAPI filters are a specific solution to Web server requests, and do not provide complete control over service methods.
As described above, previous solutions have had significant shortcomings, in that they required significant additional coding for a higher level consumer component and/or the provider of a service. Previous solutions have also failed to provide full control over services to higher level application components that use those services. For these reasons and others, it would be desirable to have a new approach to providing a service oriented architecture, which allows higher level application components using the infrastructure services to have more complete control over those infrastructure services.